Database performance can be enhanced by distributing information, such as source tables, among multiple hosts. For example, a number of hosts may store different tables in the database system, or tables can be partitioned among multiple hosts. The ability to distribute a database system among multiple hosts can provide opportunities to increase system performance, such as by distributing workloads among CPUs located at the different hosts, rather than relying on the capabilities of a single host. However, distributed systems can be more complex to recover after a crash or other disruption.
In typical database recovery schemes, a state of the database system prior to the occurrence of an interruption can be restored without using commit identifiers for in-doubt transactions, transactions which have begun a commit process, but which have not finished committing. For example, database operations that are pending when the database system is interrupted can be restarted using a new version of the database system, such as a version where the in-doubt transactions have been committed. Persisted data used to restore the database system nodes is typically stored in a sequential format, such that the persisted data can be replayed or reloaded during a recovery or restart process in sequence to restore a state of the database system. Because of this sequential storage, commit identifiers of in-doubt transactions are not needed. Room for improvement in the management of database transactions remains in database systems where commit identifiers are needed by a slave node during recovery or restart following a database system interruption.